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ABSTRACT 


Graphical  User  Interfaces  (GUI)  are  quickly  becoming  the  standard  operating  environment  for 
most  software  programs  and  operating  systems.  Ease  of  use,  rapid  learning  and  the  ability  to  retain 
complex  task  sequences  and  operations  are  some  of  the  advantages  attributed  to  this  type  of  interface. 
VxTien  properly  implemented  the  GUI  can  provide  a  natural  interaction  betvxeen  the  user  and  the 
computer.  Initial  acceptance  and  continued  use  of  any  program  can  be  greatly  enhanced  by  proper 
design  of  this  interface  It  is  expected  that  this  trend  toward  visual  representation  of  a  task's  objects 
and  actions  vsill  be  more  fully  developed  and  expanded  in  future  years.  This  thesis  explored  the 
principles  of  interface  design  with  particular  attentitm  given  to  the  specific  characteristics  associated 
with  GUI  desi,'  Unique  design  concepts  associated  with  Negotiation  Support  Systems  were  also 
considered.  These  design  te^-hniques  and  principles  were  then  applied  in  the  analysis  and  design  of 
the  graphical  user  interface  for  a  Bilateral  Negotiation  Support  System  based  on  multiple  attribute 
utility  theory.  The  program  was  written  in  Microsoft  Visual  Basic  for  use  under  the  Microsoft 
Windows  3.0  operating  environment. 
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INITIAL  DISTRIBUTION  LIST 


I.  INTRODUCTION 


A.  PURPOSE  OF  THESIS 

The  purpose  of  this  thesis  is  to  design  and  implement  a  Graphical  User  Interface 
(GUI)  based  program  for  a  Bilateral  Negotiation  Support  System  (NSS)  (Bui  & 
Sivasankaran,  1991).  The  program  is  written  to  operate  on  a  Microsoft  Windows/DOS 
operating  system  microcomputer.  It  is  expected  that  graphical  user  interfaces,  when 
properly  implemented,  can  provide  a  user  friendly  and  natural  interaction  betw'een  the 
user  and  the  decision  support  system  program.  Initial  acceptance  and  continued  use  of 
any  program  can  be  greatly  enhanced  by  proper  design  of  the  interface. 

B.  BACKGROUND 

1.  Bilateral  Negotiation  Support  Systems  (NSS) 

The  framework  upon  which  the  Bilateral  NSS  is  based  was  originally 
formulated  in  a  publication  on  Group  Decision  Support  Systems  (Bui,  1987)  and  a 
publication  on  Bilateral  Negotiation  Support  Systems  (Bui.  1991).  The  first  character- 
based,  menu-driven  Bilateral  NSS  program  based  on  this  design  was  written  in  the  Pascal 
language  in  1987  and  subsequently  translated  to  the  C  language  in  1991. 

The  Bilateral  NSS  is  a  multiple  attribute,  joint  utility  negotiation  model.  In 
its  present  form  it  supports  a  two  party  negotiation  strategy.  A  negotiation  session  can 
consist  of  up  to  ten  issues  of  contention.  Within  an  issue,  each  party  can  assign  relative 
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utilities  within  the  range  of  values  defined  by  the  party's  initial  offers.  Also,  relative 
w-eightings  can  be  assigned  to  each  issue  by  the  parties  involved.  Once  party  variables 
(weights,  utilities  and  initial  offers)  are  entered  for  both  parties,  negotiation  results  are 
calculated  and  displayed  in  tabular  and  graphical  formats. 

2.  Graphical  User  Interfaces  (GUI) 

Over  the  past  ten  years,  the  Graphical  User  Interface  has  become  the  standard 
operating  environment  for  most  software  programs.  The  beginnings  of  GUI  design  can 
be  traced  to  research  started  in  the  1970's  at  the  Xerox  Palo  Alto  Research  Center.  The 
result  of  this  initial  research  was  the  introduction  of  a  computer  with  a  GUI  interface 
called  the  Xerox  Star  8010  workstation.  It  had  a  cursor-based  interface  using  high 
resolution  graphics  and  icons.  (Norton,  1990) 

The  next  evolution  in  GUI  design  w'as  begun  by  the  Apple  Computer 
Corporation.  Apple  designed  and  introduced  the  Lisa  Computer  in  1983  after  visits  to 
the  Xerox  Palo  Alto  Research  Center  by  key  corporate  personnel.  Although  not 
commercially  successful,  it  was  the  precursor  for  the  successful  introduction  of  the 
Macintosh  Computer  in  1984.  Most  people  today  credit  the  Apple  Macintosh  as  starting 
the  "GUI  revolution." 

Realizing  the  potential  importance  of  the  GUI  design,  Microsoft  Corp)oration 
began  work  on  their  own  GUI  and  introduced  the  Windows  GUI  environment  in  1985. 
Several  revisions  of  this  GUI  followed  until  the  commercially  successful  release  of 
Windows  3.0  in  1990.  At  the  time  of  this  writing.  Microsoft  is  releasing  an  updated 
version  of  Windows  3.0  -  Windows  3.1.  It  is  expected  that  the  GUI-based  Bilateral  NSS 
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developed  for  this  thesis  will  run  faster  with  Windows  3.1.  This  current  version,  along 
with  the  Microsoft  Disk  Operating  System  (DOS),  is  the  environment  under  which  the 
Bilateral  NSS  w-as  developed. 

C.  LITER.4TLTIE  REVIEW  AND  METHODOLOGY 

The  initial  thrust  in  researching  for  this  thesis  was  in  gaining  a  basic  perspective 
on  designing  the  user  interface  for  NSS.  Several  publications  on  general  interface  design 
were  reviewed  (Lim  &.  Benbasat,  1991).  These  publications  discussed  a  broad  Sf)ectrum 
of  design  techniques  on  graphical  interfaces  as  well  as  the  character-based  interfaces  such 
as  menus  and  command  line  entry.  With  a  basic  understanding  of  interface  design,  the 
next  step  was  getting  information  on  GUI  design  for  the  IBM-PC/Windows  platform. 
The  primary  publication  used  was  the  Common  User  Access  Advanced  Interface  Design 
Guide  (IBM,  1989).  This  document  provides  a  set  of  interface  standards  for  all  Windows 
programmers  to  follow  . 

After  gaining  an  initial  feel  for  interface  design  techniques  through  the  literature 
review ,  an  overall  design  strategy  for  the  program  was  initiated.  An  initial  prototype  of 
the  various  screens  was  developed  and  presented  to  various  potential  users  for  feedback. 
Several  iterations  of  this  process  resulted  in  a  final  prototype  that  successfully  met 
general  interface  design  principles.  Implementation  consisted  of  coding  and  testing  each 
screen  module  before  the  final  integration  and  testing  for  the  entire  program. 
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D.  SCOPE  AND  DIRECTION 


The  main  focus  of  this  thesis  is  presenting  the  design  considerations  for  developing 
a  GUI-based  program.  Examples  and  techniques  unique  to  this  environment  will  be 
presented  and  explored.  Where  appropriate,  character-based  versus  GUI-based  interface 
design  considerations  will  be  contrasted. 

The  second  chapter  w  ill  open  with  a  broad  over\iew  of  general  interface  design 
principles.  Five  main  categories  of  inte.'faces  will  be  discussed  and  compared  with 
particular  attention  focused  on  the  graphical  user  interface.  The  third  chapter  will 
discuss  the  actual  design  and  implementation  of  a  Bilateral  Ni^S.  Design  features  and 
considerations  for  the  individual  modules  of  the  Bilateral  NSS  will  be  presented.  The 
final  chapter  will  summarize  the  findings  and  make  recommendations  for  future  research. 

The  framework  and  model  for  the  Bilateral  NSS  described  in  this  thesis  is 
reproduced  in  Appendix  A.  Appendix  B  excerpts  the  end  user  manual  guidelines  set 
forth  in  DOD  standard  7935A.  The  Bilateral  NSS  user's  manual  is  provided  in 
Appendix  C. 
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II.  INTERFACE  DESIGN  OF  NEGOTIATION  SUPPORT  SYSTEMS 


A.  GENERAL  INTERFACE  DESIGN  PRINCIPLES  ANT)  ISSUES 

Successful  computer  programs  begin  with  an  intelligently  designed  user  interface. 
Without  a  good  interface  there  is  little  incentive  for  the  user  to  continue  to  use  your 
program.  "...  if  the  computer  industry  is  successfully  to  extend  its  user  base  it  must 
urgently  attend  to  developing  user-friendly  interfaces”  (Coombs,  1981).  It  is  therefore 
incumbent  upon  the  program  designer  to  become  thoroughly  familiar  with  two  important 
aspects  of  good  software  design;  understanding  the  needs  of  the  intended  users  of  the 
program  and  the  generally  accepted  guidelines  of  proper  interface  design. 

This  chapter  begins  with  a  review  of  interface  design  techniques.  The  strengths 
and  weaknesses  of  the  various  designs  will  be  examined  as  well  as  the  rationale  for 
choosing  the  graphical  user  interface  over  other  possible  alternatives.  The  last  part  of 
this  chapter  will  deal  with  the  actual  design  considerations  involved  in  the  programming 
of  the  Bilateral  NSS. 

1.  Types  of  Interfaces 

In  his  book  on  designing  the  user  interface,  Shneiderman  identifies  five 
categories  of  user  interfaces  (Shneiderman,  1987).  They  are; 

•  Menu  Selection  -  In  this  method  the  user  is  presented  with  a  list  of  items  and  must 
choose  one  by  highlighting  his  choice  or  pressing  the  appropriate  key.  This  style 
is  appropriate  for  novice  and  intermediate  users.  It  is  easy  to  learn,  provides  for 
structured  decision  making  and  supports  error  handling.  Disadvantages  include  the 
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danger  of  creating  too  many  layers  of  menus  and  slowing  the  speed  of  use  for 
frequent  users  of  the  program. 


•  Form  Fill-in  -  This  method  displays  a  group  of  fields  for  user  fill-in.  The  fields 
are  normally  navigated  by  use  of  the  cursor  or  tab  keys.  This  style  is  appropriate 
when  data  entry  is  the  main  form  of  interaction.  It  simplifies  data  entry  ,  requires 
modest  training  and  permits  the  use  of  form  management  tools. 

•  Command  Language  -  This  method  relies  on  the  user  learning  a  group  of 
commands  that  are  often  complex  and  cryptic  in  nature.  This  style  is  appropriate 
for  experts  and  frequent  users  of  the  program.  It  allows  the  user  to  quickly  initiate 
commands  with  short  and  highly  complicated  syntax.  Disadvantages  include  p>oor 
error  handling  and  substantial  user  training. 

•  Natural  Language  -  This  method  allows  users  to  enter  words  or  phrases  in  a  natural 
la  guage  format.  Its  chief  advantage  is  that  it  can  relieve  the  user  from  having  to 
learn  an  obscure  command  syntax.  Disadvantages  include  the  requirement  for 
frequent  "clarification  dialogs"  and  the  possibility  of  being  slower  and  more 
cumbersome. 

•  Direct  Manipulation  (Graphical  User  Interface)  -  This  method  involves  the  visual 
representation  of  objects  and  actions  of  interest  to  the  user.  The  user  is  allowed 
to  select  from  a  visible  set  of  objects  and  act  upon  those  objects  by  means  of 
various  cursor  motion  devices  such  as  mice,  trackballs  and  keyboards.  It  is 
relatively  eas>  to  learn  and  retain  for  both  novices  and  experts.  Disadvantages 
normally  include  more  difficulty  in  programming  and  the  requirement  for  additional 
pointing  devices  and  higher  quality  displays. 


As  can  be  seen  from  the  above  list,  there  are  a  variety  of  interface  design 
methods  at  the  disposal  of  the  computer  programmer.  Choice  of  a  method  depends  on 
the  complexity  of  the  program  and  the  experience  level  of  the  programmer.  Each  one 
requires  the  programmer  to  correctly  analyze  both  the  user’s  requirements  and  the 
necessary  functionality  of  the  program.  In  a  Danish  textbook  on  interface  design 
(Nielson,  1989),  five  guidelines  for  the  process  of  user  interface  design  were  presented. 
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They  are: 


•  Know  the  user 

•  Involve  users  during  the  design 

•  Coordinate  the  total  user  interface 

•  Empirical  measurements 

•  Iterative  design  to  remove  usability  problems 

As  can  be  seen  in  the  above  guidelines,  the  user  is  a  key  element  in  almost 
all  aspects  of  interface  design.  The  programmer  must  avail  himself  of  every  opportunity 
to  get  user  input  and  feedback  during  all  stages  of  program  development.  The  final 
guideline  is  especially  critical.  Even  with  user  involvement  during  the  early  stages  of 
system  design,  until  the  user  is  able  to  interact  with  your  program,  the  success  of  your 
design  is  highly  tentative  at  best.  When  practicable,  a  design  philosophy  based  on  rapid 
prototyping  will  yield  more  success  than  the  ''waterfall"  method  of  system  design  (Page- 
Jones,  1988). 

2.  Graphical  User  Interface 

Until  the  unveiling  of  the  Apple  Macintosh  in  1984,  almost  all  interface 
design  followed  the  general  guidelines  enumerated  in  the  first  four  of  Shneiderman's 
methods.  Although  still  used  for  certain  applications,  the  direct  manipulation  or 
graphical  user  interface  has  supplanted  the  earlier  design  methods  as  today’s  design  of 
choice.  Indeed,  today’s  software  applications  need  graphical  user  interfaces  to  sell 
(Zachary,  1990). 
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Currently,  there  are  a  wide  variety  of  GUIs  running  on  almost  all  available 
hardware/software  platforms.  Some  examples  are: 

•  Microsoft  Windows  3.0  on  IBM  compatible  systems 

•  GeoWorks  Ensemble  on  IBM  compatible  systems 

•  IBM  Presentation  Manager  for  OS/2 

•  Motif  for  Unix-based  systems 

•  NextStep  for  the  Next  computer 

In  a  tutorial  on  graphical  interface  design  (Marcus.  1990),  the  author  stresses 
the  importance  of  visually  communicating  a  program's  data  and  functions.  Proper  use 
of  graphic  design  principles  and  an  effective  use  of  "visible  language"  contributes  to 
improved  visual  communication.  The  author  defines  visible  language  as  "...all  the 
graphical  techniques  used  to  communicate  the  message  or  content."  Some  aspects  of 
visible  language  are; 

•  Layout:  formats,  proportions  and  2-D  and  3-D  organization 

•  Typography:  selection  of  typefaces  and  typesetting 

•  Color  and  texture:  color,  texture  and  light  that  convey  pictorial  reality 

•  Imagery:  signs,  icons  and  symbols 

•  Animation:  a  dynamic  or  kinetic  display  that  is  especially  important  for  video 
related  imagery 

•  Sequencing:  the  overall  approach  to  visual  storytelling 

•  Sound:  abstract,  vocal, concrete  or  musical  cues 
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•  Visual  Identity:  the  additional,  unique  rules  that  lend  overall  consistency  to  a  user 
interface 

Careful  manipulation  of  this  visible  language  and  judicious  adherence  to  the 
following  set  of  design  principles  will  help  to  ensure  a  successful  well  thought  out 
graphical  design.  The  three  principles  and  amplifying  concepts  within  each  principle  are 
detailed  belou . 

a.  Principles  of  Graphic  Design 

(I  I  Organize 

Provide  the  user  with  a  clear  and  consistent  conceptual  structure. 
Four  important  concepts  associated  with  this  principle  arc: 

•  Consistency  -  observe  the  same  conventions  and  rules  for  all  elements  of  the  GUI. 

•  Screen  layout  -  standardize  the  screen  layout  and  group  related  items. 

•  Relationships  -  link  related  elements  and  disassociate  unrelated  elements. 

•  Navigability  -  provide  an  initial  focus  for  the  user;  direct  attention  to  important 
items;  and  assist  in  navigation  throughout  the  material. 

(2)  Economize 

Maximize  the  effectiveness  of  a  minimal  set  of  cues.  Four  concepts 
associated  with  this  principle  are: 

•  Simplicity  -  include  only  those  elements  that  are  essential  for  communication. 

•  Clarity  -  design  all  components  so  that  their  meaning  is  not  ambiguous. 
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•  Distinctiveness  -  distinguish  important  properties  of  essential  elements. 

•  Emphasis  -  make  the  most  important  elements  salient,  de-emphasize  non-critical 
elements  and  minimize  clutter  so  that  important  information  is  not  hidden. 


(3)  Communicate 

Match  the  presentation  to  the  capabilities  of  the  user.  Six  concepts 
associated  with  this  principle  are; 


•  Legibility  -  design  characters,  symbols  and  graphic  elements  to  be  easily  noticeable 
and  distinguishable. 

•  Readability  -  make  the  display  easy  to  interpret  as  well  as  inviting  and  attractive. 

•  Typography  -  use  a  small  number  of  typiefaces.  Generally,  you  should  use  a 
maximum  of  three  typefaces  in  a  maximum  of  three  point  sizes. 

•  Symbolism  -  carefully  design  icons,  charts,  maps  and  other  imagery  to  properly 
convey  the  desired  contents. 

•  Multiple  Views  -  provide  multiple  perspectives  on  the  display  of  complex  structures 
and  processes. 

•  Color/Texture  -  use  a  consistent  color  code  for  screen  displays  and  a  maximum  of 
five  plus  or  minus  two  colors  in  each  display. 

b.  Hardware  Elements 

Common  to  all  GUIs  are  several  hardware  elements.  They  are: 

•  High  resolution  graphics  displays 

•  Pointing  devices  such  as  mice,  trackballs  and  pens 

•  Keyboards 
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c.  Software  Elements 


In  addition  to  common  pieces  of  hardware,  there  are  software  elements 
common  to  most  GUIs.  They  are: 

•  Windows 

•  Pull-down  menus 

•  Dialog  boxes 

•  Icons 

•  Buttons  and  scroll  bars 

•  Cursors 


Careful  examination  of  the  Microsoft  Window  s  3.0  interface  will  reveal 
a  general  adherence  to  the  principles  and  elements  enumerated  above.  To  accomplish 
this,  the  Microsoft  Windows  3.0  system  was  designed  using  GUI  standards  detailed  in 
an  IBM  document  called  the  Common  User  Access  Advanced  Interface  Design  Guide 
(IBM,  1989).  Common  User  Access  (CUA)  is  a  portion  of  IBM's  System  Application 
Architecture  (SAA)  that  defines  an  overall  set  of  interface  standards.  Conformance  to 
the  CUA  ensures  consistency  of  the  interface  across  platforms  as  well  as  software 
applications  on  a  single  platform. 
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B.  GUI  DESIGN  FOR  NEGOTIATION  SUPPORT  SYSTEMS 


The  GUI  guidelines  presented  in  the  previous  section  are  in  principle  applicable  to 
all  software  interfaces.  For  NSS  software,  there  are,  however,  some  additional  design 
concepts  that  should  be  considered. 

Bui  (1987)  argues  that  the  following  topics  should  be  tal;en  into  consideration  when 
designing  for  a  group  decision  environment 


First,  a  Group  Decision  Support  System  (GDSS)  should  provide  both  formal  and 
informal  man -machine- man  interfaces  to  enhance  information  exchange  within 
group  members.  Second,  the  GDSS  should  be  designed  in  such  a  way  that  (i)  it 
becomes  favorable  media  for  solving  group  problems,  and  (ii)  it  ensures  that 
decision  makers  do  not  waste  unnecessary  resources  in  interpersonal  exchange  at 
the  expense  of  a  thorough  discussion  of  the  object  of  the  group  problem. 

...  a  user  interface  of  a  DSS  should  (i)  be  transparent  and  consistent  to  make  the 
system  easy  to  learn,  use  and  remember;  (ii)  be  suitable  for  both  novice  and  expert 
use;  (iii)  let  the  user  have  control  of  the  system  and  feel  competent  in  task 
performance;  (iv)  promote  effective  usage  and  better  decision-making;  (v)  and  be 
efficient  in  the  use  of  system  resources  (Stohr  and  White,  1982;  Shneiderman, 
1986).  Although  these  design  principles  should  prevail  in  building  GDSS, 
importance  should  be  given  more  to  the  concept  of  ease-of-use  and  transparency. 

...  DSS  users  are  often  decision  makers  who  deal  with  strategic  and  ill-structured 
problems.  It  is  reasonable  to  expect  that  (i)  the  frequency  of  GDSS  use  is  low  and, 
(ii)  familiarity  with  computers  is  insignificant  to  none.  Under  such  a  decision 
environment,  a  comprehensive,  structured  and  controlled  interface,  such  as 
sequences  of  hierarchical  menus  or  carefully  designed  queries,  seems  to  be  most 
appropriate  in  order  to  satisfy  the  five  design  principles  mentioned  above. 
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In  addition  to  Bui's  arguments,  Lim  and  Benbasat  (1991)  propose  a  conceptual 
framework  for  designing  software  interfaces  for  group  decision  support  systems.  They 
suggest  four  dimensions  that  need  to  be  examined  in  group  interface  design; 


•  Concurrency  -  this  dimension  describes  the  type  of  collaboration  between  members 
of  a  work  group.  The  temporal  aspect  of  this  dimension  concerns  itself  w'ith 
whether  the  collaboration  is  synchronous  or  asynchronous.  The  spatial  aspect 
describes  whether  the  collaborators  are  collocated  or  dispersed. 

•  Content  -  this  dimension  describes  the  type  of  message  passed  between  members 
of  a  group.  There  are  tvso  categories  -  task-oriented  or  social-emotional. 
Computer-mediated  communication  tends  to  be  richer  in  task-oriented  than  social- 
emotional  messages. 

•  Path  -  this  dimension  describes  the  type  of  communication  path.  Some  of  these 
paths  may  be  collaborator  -  collaborator,  collaborator  -  works  ,  tion  - 
collaborator,  collaborator  -  display,  etc. 

•  Channel  -  this  dimension  describes  the  characteristics  of  the  medium  through  which 
communication  occurs.  Two  issues  are  discussed  -  teclmoloyiy  support  and  mode. 
The  modes  by  which  collaborators  communicate  may  be  classified  by  the  degree 
of  social  presence  conveyed.  In  a  computer-mediated  context,  the  textual  and 
graphical/symbolic  modes  at  the  low  end  of  the  social  presence  spectrum  are 
predominant. 


The  above  mentioned  design  considerations  are  not  totally  unique  concepts. 
Rather,  they  build  upon  the  general  design  techniques  enumerated  in  the  previous  section. 
They  attempt  to  address  some  of  the  special  characteristics  inherent  in  a  computer- 
mediated  environment.  When  applied  to  the  GUI  design  of  the  Bilateral  NSS,  they  give 
the  designer  additional  insight  into  the  type  of  person  that  uses  a  NSS  program  and  some 
of  the  environmental  issues  he  may  be  exposed  to. 
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The  next  section  will  take  the  design  ideas  presented  in  this  chapter  and  attempt  to 
apply  them  to  the  design  of  a  Bilateral  NSS.  Although  certain  aspects  of  the  above 
discussion  are  not  applicable  to  the  design  of  this  particular  Bilateral  NSS,  the  general 
guiding  principles  and  special  considerations  of  this  project  will  be  explained. 
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III.  DESIGN  AND  IMPLEMENTATION  OF  A  BILATERAL  NSS 


This  section  presents  the  philosophy  used  in  designing  the  Bilateral  NSS.  The  first 
part  of  this  section  discusses  the  GUI  specifications  for  the  Bilateral  NSS.  The  second 
section  discusses  the  design  considerations  for  the  program  as  a  whole.  The  last  part 
breaks  down  the  Bilateral  NSS  program  into  its  lanctional  pans  and  discusses  the 
programming  and  design  considerations  used. 

A.  Gl  1  SPECIFICATIONS 

Based  on  the  previous  discussion  of  general  graphic  design  principles  and  the 
framework  proposed  by  Lim  and  Benbasat.  the  following  specifications  have  been 
determined  for  the  GUI  interface; 

1.  Concurrency 

a.  Temporal 

The  system  should  be  distributed  in  time.  Both  negotiating  parties  can 
access  and  use  the  Bilateral  NSS  at  different  points  in  time. 

b.  Spatial 

The  system  should  be  distributed  in  space.  Both  negotiating  parties  can 
either  use  the  Bilateral  NSS  in  face-to-face  mode  or  at  two  different  physical  locations. 
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2.  Content 


a.  Task-oriented 

The  system  should  use  a  formal  and  comprehensive  multiple  attribute 
utility  theor>'  to  define  negotiators'  tasks. 

b.  Social-emotional 
N/A 

3.  Path 

As  a  minimum,  the  Bilateral  NSS  should  support  the  following 
communication  paths; 

•  collaborator  -  collaborator 

•  collaborator  -  workstation  -  collaborator 

•  collaborator  -  display 

4.  Channel 

The  main  thrust  of  the  Bilateral  NSS  is  its  application  of  multiple  attribute 
utility  theory  to  the  negotiation  process.  Therefore,  the  mode  of  operation  can  be  at  the 
low  end  of  the  social  presence  spectrum.  Ideally  then,  the  predominant  sub-mode  should 
be  graphical/symbolic  if  we  are  to  exploit  the  advantages  of  the  graphical  user  interface. 

Particular  aspects  of  designing  the  visual  representation  presented  to  the  user  are 
discussed  in  the  next  section. 
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B.  METHODOLOGY 


The  first  step  taken  in  designing  this  program  was  to  look  at  the  original  program 
as  it  w'as  implemented  in  the  C  language  (Gilley.  1991).  The  screen  layouts  and  menu 
structure  were  penciled  out  and  the  general  flow  between  them  were  analyzed.  After 
initially  trying  to  design  the  program  using  the  old  system  structure,  it  became  apparent 
that  trying  to  directly  conven  it  over  to  a  graphical  interface  would  not  be  successful. 
Although  the  menu-driven  structure  was  adequate  for  the  character-based  interface  that 
it  was  originally  written  for.  a  direct  conversion  would  not  in  any  way  use  the  graphical 
user  interface  to  its  fullest  advantage. 

The  second  step  was  to  come  up  with  an  overall  flowchart  of  the  program.  All  the 
information  needed  to  be  input  by  the  user  and  all  the  information  needed  to  be  presented 
to  the  user  was  vs  ruten  dowtr.  This  data  was  then  broken  down  into  logical  groupings. 
The  next  jtep  was  to  figure  out  how  best  to  present  this  data  to  the  user  in  a  clear  and 
logical  manner.  After  designing  the  initial  prototype  that  included  the  general  screen 
layouts  and  the  interaction  between  them,  it  was  presented  to  several  potential  users  for 
feedback.  Several  iterations  of  this  cycle  eventually  produced  the  final  working  version. 

The  initial  design  layout  was  developed  by  adhering  as  much  as  possible  to  the 
guidelines  outlined  in  the  Common  User  Access  guide.  This  document  details  a  standard 
set  of  guidelines  to  follow  when  designing  graphical  interfaces  for  Windows  and  OS/2 
programs.  Standard  menu  bar  configurations,  screen  layouts  and  minimum  screen 
controls  are  some  of  the  many  design  considerations  presented.  Some  of  the  screen 
design  issues  that  were  standardized  across  the  entire  program  are  (See  Figure  1): 
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•  Button  position  -  all  buttons  are  located  on  the  bottom  righthand  side  of  the  screen. 
If  the  width  of  the  screen  is  sufficiently  small,  the  buttons  are  equally  spaced 
across  the  entire  bottom.  The  Help  button  is  always  the  rightmost  button  in  the 
row . 

•  Button  types  -  almost  all  screens  have  an  OK  and  Cancel  button.  If  both  are 
available  the  OK  button  is  always  on  the  left. 

•  Colors  -  a  similar  color  scheme  is  used  for  all  screens.  A  limited  number  of  colors 
were  used  when  groups  of  data  needed  to  be  highlighted. 

•  Help  system  -  a  Help  butuni  is  available  on  all  screens.  This  button  "ovides 
context-sensitive  help  for  the  current  operation. 


Party  A  Priorities 


Select  Method  for  Rankirrg  Issues 


<¥'  Equal  Weighting 
O  Direct  Prioritization 
O  Pairwise  Compafison 


OK 


Cancel 


Figure  1 

Sample  Program  Screen 


C.  INDIVIDUAL  SCREEN  DESIGN 

The  following  sections  discuss  the  design  considerations  used  in  developing  the 
screen  layouts  for  the  various  portions  of  the  Bilateral  NSS  program. 

1,  Main  Bilateral  NSS  Screen 

Figure  2  shows  the  opening  screen  the  user  sees  when  starting  the  Bilateral 
NSS  program.  Window  design  components  normally  available  on  all  Windows  3.0 
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application  programs  were  used.  These  include  the  upper  left  Control  Menu  button,  the 
upper  righthand  minimize  and  maximize  buttons  and  the  main  Action  Bar.  The 
arrangement  of  the  two  Action  Bar  items  are  in  compliance  with  the  CUA  guidelines. 
The  background  graphic  of  the  shaking  hands  was  included  to  visually  convey  the  intent 
of  the  program. 


Figure  2 

Bilateral  NSS  Opening  Screen 
2.  File  Menu  Screens 

The  four  screens  that  follow  are  associated  with  the  commands  listed  under 
the  File  Menu  on  the  Action  Bar. 

a.  Start  .S'ew  Session  Screen 

Figure  3  shows  the  screen  displayed  when  the  user  selects  the  Starr  New 
Session  command  under  the  File  Menu.  This  command  is  selected  to  begin  a  new 
negotiation  session.  The  user  is  prompted  to  enter  the  filename  he  wishes  to  store  the 
data  under.  The  standard  set  of  control  buttons  are  located  along  the  bottom  of  the 
screen  for  consistency  with  all  other  screens.  A  Cancel  button  is  provided  to  allow  the 
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user  to  cancel  the  command  if  he  decides  to.  As  always,  a  Help  button  (denoted  by  the 
?  symbol)  is  the  rightmost  button. 


b.  Open  Prior  Session  Screen 

Figure  4  sho\s  s  the  screen  displayed  when  the  user  selects  the  Open  Prior 
Session  command  under  the  File  Menu.  The  standard  complement  of  control  buttons  is 
again  located  on  the  bottom  of  the  screen  in  the  same  relative  position  as  all  other 
screens.  This  particular  orientation  of  the  file,  directory  and  drive  list  boxes  is  the  new 
standard  for  all  applications  written  for  Windows  3.0.  This  particular  screen  will  look 
familiar  to  all  users  who  run  other  Windows  applications. 
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Open  Prior  Session 
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Figure  4 

Open  Prior  Session  Screen 


c.  Save  Current  Session  and  Save  Current  Session  As  Screens 

Figures  5  and  6  show  the  screens  the  user  sees  when  selecting  the  Save 
Current  Session  and  Save  Current  Session  As  commands,  respectively. 


Save  Session 

Save  data  changes  foi 
current  session? 

Filename:  Testlile 


Save 


Cancel 


Figure  5 

Save  Current  Session  Screen 


The  button  layouts  are  consistent  with  other  program  screens.  The 
screen  designs  are  very  similar  since  they  are  used  for  the  same  basic  purpose.  For  the 
Save  Current  Session  As  command,  the  user  is  provided  with  a  text  box  to  enter  any  eight 
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character  filename.  If  non-allowable  characters  are  entered,  a  message  box  indicating 
the  error  is  displayed. 


Save  Session  As 


Enter  File  Name: 
T  eslfile 


Save 

Cancel 

■> 

• 

Figure  6 

Save  Current  Session  As 


3.  Help  Menu  Screens 

The  two  screens  that  follow  are  associated  with  the  commands  that  are  listed 
under  the  Help  Menu  on  the  Action  Bar. 

a.  Index  Screen 

Figure  7  shows  the  screen  displayed  when  the  user  selects  the  Index 
command  located  under  the  Help  Menu.  This  screen  is  the  only  one  that  was  not 
designed  using  the  same  control  layout  considerations  as  the  other  screens.  The  use  of 
OK  and  Cancel  buttons  was  not  appropriate  since  their  meaning  to  the  user  would  not 
have  been  clear  in  this  situation.  To  get  the  user’s  attention,  a  set  of  program  topics  in 
the  center  of  the  screen  are  grouped  together.  The  labeling  of  the  Get  Help  and  Quit 
buttons  was  used  to  clearly  convey  their  intent  if  pressed. 
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b.  About...  Screen 

Figure  8  shows  the  screen  displayed  when  the  user  selects  the  About... 
command  located  under  the  Help  Menu.  It  is  common  practice  to  include  this  command 
under  the  Help  Menu  to  indicate  the  program's  current  version,  authors  and  any  other 
information  deemed  appropriate. 
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4.  Main  Selection  Menu  Screen 

Figure  9  shows  the  screen  displayed  when  the  user  starts  the  program  by 
either  opening  a  prior  session  or  by  starling  a  new  session.  The  ordering  of  the  menu 
items  was  chosen  so  that  the  first  item  a  user  would  most  likely  go  to  was  displayed  at 
the  top.  Additionally,  the  default  radio  button  is  also  the  first  item.  The  double  column 
format  was  chosen  as  the  most  appropriate  design  to  both  limit  redundancy  and  provide 
a  symmetrical  display.  Button  layouts  are  standard  and  the  Quii  button  was  used  instead 
of  the  Cancel  button  since  it  would  convey  a  clearer  meaning  to  the  action  of  leaving  the 
Main  Selection  Menu. 
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Figure  9 

Main  Selection  Menu  Screen 


5.  Issue  Parameters  Screen 


Figure  10  shows  the  screen  displayed  when  the  user  selects  the  Issue 
Parameters  item  from  the  Main  Selection  Menu,  The  lines  were  designed  so  that  the 
user’s  cursor  is  automatically  mo\ed  to  the  next  available  text  box  when  he  presses  the 
Enter  key.  This  helps  to  speed  up  user  data  entry.  To  enter  an  initial  starting  offer  the 
user  has  two  choices.  He  can  directly  enter  the  value  in  the  text  box  provided  or  use  the 
scroll  bar  located  beside  each  text  box.  Two  additional  control  buttons.  Add  New  Issue 
and  Delete  Issue,  are  provided  to  give  the  user  a  positive  means  of  initiating  those 
actions. 
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Figure  10 

Issue  Parameters  Screen 


6.  Name  or  Party  Screen 

Figure  1 1  shows  the  screen  displayed  when  the  user  selects  the  Name  or 
Parry  item  in  the  Main  Selection  Menu.  This  screen  uses  the  standard  button  layout  with 
two  additional  text  boxes.  If  the  user  exceeds  the  15-character  limit  for  either  text  box, 
a  message  to  that  effect  wilt  be  displayed. 


**  Parly  A  Data  Update  Screen 

Negotiatoi  Name 

Ambassador  Hall 

Negotiatof  Parly 

United  Stales 

OK  1 

Carwrel  1 

. . - . - . '1 

Figure  11 

Name  or  Party  Data  Screen 
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7.  Issue  Priorities  Selection  Screen 

Figure  12  shows  the  screen  displayed  when  the  user  selects  the  Issue 
Priorities  item  from  the  Main  Selection  Menu.  The  screen  is  a  standard  option  button 
screen  with  the  normal  three  button  layout. 


_ Party  A  Priorities 

Select  Method  for  Ranking  Issues 


^  Equal  Weighting 
O  Direct  Prioritization 
O  Pairwise  Comparison 


OK 


Cancel 


Figure  12 

Issue  Priorities  Screen 


8.  Issue  Priorities  (Direct  Entry)  Screen 

Figure  13  shows  the  screen  displayed  when  the  user  selects  the  Direa 
Prioritization  option  from  the  Issue  Priorities  Selection  Menu.  Values  can  be  entered  in 
the  Weight  column  by  direct  entry  in  the  text  box  or  by  using  the  scroll  bars  located 
beside  each  text  box.  The  standard  three  button  layout  is  used  in  this  screen  also. 
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Figure  13 

Issue  Priorities  (Direct  Entry)  Screen 
9.  Utility  Values  Screen 

Figure  14  shows  the  screen  displayed  when  the  user  selects  the  Uriliry  Values 
item  from  the  Main  Selection  Menu.  The  main  design  consideration  in  setting  up  this 
screen  was  how  to  make  user  entry  of  utility  data  as  simple  and  intuitive  as  possible.  To 
provide  a  graphical  look  to  the  display,  seven  columns  of  1 1  radio  buttons  were  used. 
The  user  simply  has  to  click  the  desired  button  in  each  column  to  make  his  preference. 
The  completed  display  presents  the  data  in  an  x-y  graph  fashion.  Since  there  are  seven 
utility  values  associated  with  each  issue  a  separate  box  was  provided  to  allow  the  user 
to  select  which  issue  he  would  enter  data  for.  The  remaining  buttons  are  in  a  standard 
layout. 
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10.  Negotiation  Results  Screen 

Figure  15  shows  the  screen  displayed  when  the  user  selects  the  Negotiation 
Results  item  from  the  Main  Selection  Menu.  Based  upon  the  type  of  data  presented,  the 
tabular  format  was  the  most  logical  choice.  The  column  total  text  boxes  were  separated 
from  the  rest  of  the  data  to  give  the  user  a  clearer  presentation.  A  distinctly  different 
color  was  chosen  for  the  Scratch  Pad  column  that  allows  user  modification  to  better 
indicate  its  unique  nature.  Descriptive  names  were  chosen  for  the  screen  buttons  to 
clearly  indicate  their  purpose. 
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Figure  15 

Negotiation  Results  Screen 


1 1 .  Display  Graphs  Screen 

Figure  16  shows  the  screen  displayed  when  the  user  selects  the  Display- 
Graphs  button  from  the  Negotiation  Results  screen.  To  augment  the  tabular  data 
presented  in  the  Negotiation  Results  screen,  a  graphical  representation  of  the  data  was 
provided.  The  graph  portion  of  the  screen  uses  a  three  color  layout  to  clearly  present 
the  data.  The  display  grid  is  re-scaled  for  each  issue  to  provide  the  maximum  usable 
display  area  for  each  set  of  data.  A  standard  option  button  selection  scheme  was  chosen 
to  select  the  desired  issue  for  display.  Two  option  buttons  are  also  included  to  allow  the 
user  to  toggle  between  weighted  and  unweighted  data. 
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Figure  16 

Display  Graphs  Screen 
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IV.  SUMMARY  AND  SUGGESTIONS  FOR  FLTURE  RESEARCH 


A.  SUMMARY 

The  goal  of  designing  a  graphical  user  interface  for  the  Bilateral  NSS  was  achieved. 
The  GUI  design  followed  the  commonly  accepted  graphic  design  principles  enumerated 
in  this  thesis.  Additionally,  the  CUA  standards  outlined  in  IBM's  System  Application 
Architecture  were  followed  to  the  maximum  extent  possible.  It  is  believ  ed  that  the  GUI- 
based  version  of  the  Bilateral  NSS  will  receive  a  favorable  response  in  comparison  to  the 
original  character-based  program. 

B.  SUGGESTIONS  FOR  R  TIRE  RESEARCH 

Several  follow  on  studies  are  suggested  as  a  result  of  this  thesis.  First,  a  study 
could  be  conducted  to  measure  user  preference  between  the  GUI-based  and  character- 
based  programs.  Since  the  task  sets  of  the  programs  are  identical,  a  valid  comparison 
could  be  made.  Second,  additional  capabilities  could  be  added  to  the  original  program 
to  further  enhance  the  negotiation  process.  This  might  include  dynamic  updating  of 
graphs  and  tables  with  multiple  views  of  the  information  on  the  screen.  Third,  the 
program  could  be  integrated  into  a  broader  Group  Decision  Support  System.  The 
Bilateral  NSS  could  be  added  as  a  module  to  such  a  system. 
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Abstract 

This  paper  presents  a  bilateral  Negotiation 
Support  System  (NSS)  based  on  a  multi-attribute 
tniUty  model  that  adapts  a  fuzzy  set  methodology 
in  determining  user's  preference  functions  The 
system  can  concurrently  handle  negotiations  that 
span  across  multiple  mediating  issues  in  a 
manner  that  increases  the  joint  utilit}'  of  both 
po’-tics  The  N’SS  is  expected  to  impart  a  more 
interactive  and  realistic  approach  to  capturing 
uncertainties  while  developing  the  utilin 
functions  using  the  standard  approach.  The 
potentiality  of  the  proposed  NSS  lies  in  its  ability 
to  allow  negotiators  to  evaluate  potential  treaties 
quickly,  explore  alternate  arrangements  that 
reveal  to  be  more  advantageous  to  both  parties 
than  those  which  arc  arrived  at  intuitively. 


1.  Introduction 

Negotiations  have  always  been  an 
integral  part  of  business,  organizational 
management,  and  international  affairs.  With  ever 
increasing  competitiveness,  negotiations  require 
greater  sophistication  an'^  faster  recnlulion 


Today  the  information  and  knowledge  of  the 
parties  involved  arc  more  technologically 
complex,  making  it  more  difficult  to  crisply 
define  agreements  leading  to  a  compromise. 
Oftentimes,  each  party  to  the  negotiation  knows 
conceptually  the  multiple  issues  of  the  problem 
in  fairly  good  detail,  but  this  is  not  sufficient  to 
define  each  other’s  preference/utility  functioas  in 
a  deterministic  an  interactive  fashion.  Current 
systems,  however,  can  handle  only  deterministic 
inputs.  In  reality,  utility  functions  are  not 
deterministic  and  negotiators  are  willing  to  budge 
their  positioas  in  small  variants  during  actual 
negotiations. 

This  paper  proposes  an  extension  to  a 
Pareto-optimum  model  that  maximizes  the 
utilities  of  the  two  parties  using  the  fuzzy  set 
concept  to  capture  the  negotiators’  preferences 
function.  The  paper  is  organized  as  follows. 
Section  2  addresses  the  problems  in  bilateral 
negotiations.  Design  issues  for  building  bilateral 
Negotiation  Support  Systems  (NSS)  arc 
discussed  in  section  3.  Section  4  lays  down  the 
basic  steps  of  an  interactive  multi -attribute  model 
for  negotiation  involving  multiple  treaties 
between  two  parties.  In  section  5,  we  explain 
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i!ic  use  of  fu77,y  sets  in  formulating  negotiators’ 
preferences  as  an  improved  means  for  the  ulilits 
modeling.  Section  6  illustrates  the  model  using 
an  example. 


2.  Background 

Traditionally,  bilateral  negotiation  is 
often  viewed  as  a  distributive  bargaining  in  dial 
it  operates  on  the  notion  of  a  ''fixed  pie"  which 
must  he  shared  between  the  two  parties.  Bodi 
protagonists  seek  to  maximi7e  their  own  goals 
without  concern  for  the  other.  Research  has 
shown  that  distributive  bargaining  or  die  wiri- 
lose  approach  leads  to  capita!i7.ing  on  power 
differentials,  escalating  hostilities,  suboptimal 
agreements,  and  ultimately,  an  uncooperative 
relationship  for  future  negodations  (e.g.,  Lcwicki 
and  Lilterer,  1985). 

An  alternative  approach  is  die  integrative 
bargaining  or  win-win  method.  This  seeks  to 
rc'iolvc  conflict  with  a  set  of  procedures  that 
pemiit  both  sides  to  maximi7C  their  objectives. 
Inicgrativc  bargaining  generates  solutions  that 
yield  high  joint  benenis,  thus  contributing  to  a 
more  positive  relationship  (Tishcr  and  Ury  ,  1981; 
Pruitt,  1981). 

Real  life  negotiations  arc,  however, 
characterized  by  a  mixture  of  distributive  and 
integrative  elements.  This  phenomenon  is 
known  as  mixed-motive  paradigm.  Hence,  it  is 
important  to  identify  interest  differentials  quickly 
to  help  negotiators  diagnose  and  reduce  conflicts, 
thus  moving  towards  integrative  bargaining. 

There  are  a  number  of  problems 
associated  with  negotiation.  In  a  bilateral 
negotiation,  the  protagonists  assume  that  their 
interests  are  always  in  conflict  with  each  other. 
Bazerman  (1983)  argues  that  this  entrenched 
assumption  inhibits  the  creativity  and  problem¬ 
solving  necessary  for  the  development  of 
integrative  solutions.  Empirical  studies  have  also 


found  that  negotiators  may  not  always  be 
cognizant  of  their  judgment  criteria.  Further, 
they  may  not  be  able  to  assess  correctly  the  view 
of  their  counterparts  (KJeinmuntz,  1990).  Social 
and  emotional  factors  have  also  been  found  to 
affect  objectivity  and  rationality  in  negotiations. 
Kessler  (1978)  suggests  that  successful  conflict 
resolution  depends  on  successful  use  of 
techniques  that  could  handle  .socio-emotional  and 
cognitive  bias  issues  inherent  in  conflict 
situations.  As  discussed  later  in  this  paper,  we 
argue  that  by  using  a  formal  and  comprehensive 
methodology  for  negotiations,  the  parties 
involved  -  possibly  the  arbitrator  as  well  - 
could  provide  a  structure  for  systematic 
information  exchange  and  f'culd  lessen  the 
persona!  biases  of  both  parties.  A  computerized 
system  that  implements  this  methodology  will  be 
very  useful  in  negotiations. 


3.  A  Framework  for  Bilateral  NSS 

Figure  1  depicts  a  framew-ork  for 
designing  a  NSS  for  bilateral  negotiation  based 
on  the  Type  VI  of  GDSS  defined  by  Bui  (1987). 
Each  party  can  have  his/her  own  DSS  that 
contains  models  customized  to  his/her  needs  that 
individually  describe  the  issues  (DSSl  and 
DSS2)  The  Negotiation  Module  allow'S  the 
negotiators  to  engage  in  a  joint  and  open 
modeling  effort.  In  practice,  technical  experts 
and  advisors  usually  supply  the  bulk  of 
information  to  the  negotiators  either  before  or 
during  the  negotiation  process.  Even  if  such 
information  is  accurate  and  complete,  there  is  no 
reason  why  the  negotiators  themselves  could  not 
■exercise  their  freedom  of  choice  at  the  time  of 
negotiation  through  joint  concession,  and 
experimentation  of  simpler  models  of  their  owo. 
Nyhart  and  Samarasan  (1987)  contend  that  this 
can  help  the  negotiators  appreciate  better  the 
strengths  and  weaknesses  of  the  other  party’s 
position  and  arguments.  A  joint  and  open 
modeling  effort  may  be  to  the  advantage  of  both 
parties. 
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Figure  1.  A  Framework  for  Bilateral  NSS 


The  NSS  should  provide  a  model-based 
interactive  facilitation  process  that  offers  a 
comprehensive  framework  to  allow  the  parties  to 
concentrate  on  joint  problem-solving  rather  than 
on  convoluted  arguments  The  objectives  of 
using  a  NSS  arc  listed  below  : 

1.  Establish  a  consensual  database  as  a 
foundation  for  negotiation, 

2.  Evaluate  the  impact  of  perceived 
uncertainty, 

3.  Provide  communication  links  for 
bargaining  and  di,scussion, 

4.  Suggest  restructuring  for  non-cooperative 
issues,  and 

5.  Help  search  for  agreements  through 
Pareto-optimization. 

Computer  support  can  be  used  to  assist 
the  negotiators  in  interactive  information 
elicitation  and  process  them  in  an  orderly 
manner.  It  can  al.so  update  data  as  inputs  are 
entered,  and  present  the  results  of  analysis  both 
tabularly  and  pictorially.  It  should  also  act  as  a 
tool  to  let  negotiators  know  that  their 
compromises  or  concessions  can  be  implemented 


and  will  produce  the  desired  and  agreed-upon 
results. 


4.  An  Interactive  Procedure 
for  Bilateral  Negotiation 

This  section  focuses  on  the  negotiation 
module  described  in  Figure  1.  It  describes  a 
formal  and  comprehensive  model  for  joint 
problem  solving.  The  purpose  of  the  model  is  to 
focus  on  asymmetries  of  interests  between  the 
two  parties  so  that  the  terms  of  the  final  treaty 
are  better  for  both  (Barclay  and  Peterson,  1978). 
The  whole  algorithm  is  based  on  the  Pareto 
principle  applied  to  a  bilateral  negotiation 
situation.  A  treaty  is  Pareto  optimum  when  it  is 
no  longer  possible  to  increase  the  utility  of  one 
party  without  decreasing  the  utility  of  the  other. 
A  good  treaty  is  one  that  yields  to  each  party 
those  issues  which  are  more  important  to 
him/her.  Thus  the  two  parties  should  try  to  push 
the  negotiation  toward  the  Pareto  optimum  by 
capitalizing  on  asymmetries  of  interest,  and 
sometimes  by  redefining  the  situation  to  reveal 
more  asymmetries. 
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The  essence  of  the  procedure  is  described  below: 

Step  /  Identify  the  major  treaties  which  the  two 
panics  would  like  to  sign.  For  example,  say  the 
U.S.  and  a  host  country  are  negotiating  on  the 
extension  of  a  military  base  treaty  and 
establishing  a  bilateral  trade  treaty. 

Step  2.  For  each  of  the  treaties  being  considered, 
identify  a  common  .set  of  major  issues  about 
which  the  two  parties  disagree.  The  initial 
positions  of  the  parties  on  each  of  the  issues 
should  be  stated.  Assume  that  for  the  military 
base  treaty,  the  negotiators  have  identified  the 
issues  important  to  their  nations  as  duration  of 
the  use  of  the  military  base  by  the  U.S.,  civil 
jurisdiction  of  the  host  country  over  the  military 
personnel,  and  U.S.  economic  compensation. 

Step  3  Each  party  assigns  a  relative  weight  to 
each  of  Uie  issues.  It  is  important  to  understand 
the  meaning  of  die  relative  weight  in  a  bilateral 
negotiation  context.  Tlie  weights  represent  the 
relative  importance  of  the  difference  between  the 
parties'  position.  For  example,  if  the  U.S  gives 
a  weight  of  20  points  to  duration  and  10  to 
economic  compensation,  the  U.S.  docs  not 
consider  the  first  issue  to  be  two  times  as 
important  as  the  second  issue.  Rather,  the  20/10 
ratio  implies  that  the  U.S.  considers  the  change 
from  the  host  position  to  the  U.S.  position  on  the 
economic  compensation  issue  to  be  twice  as 
important  as  the  change  from  the  host  position  to 
the  U.S.  position  on  the  duration  issue.  A.ssume 
that  the  weights  for  Ihc  three  issues  arc 
(50.30.20)  and  (65,5,30)  for  the  U.S.  and  the 
host  country  respectively. 

Siep  4.  Define  the  range  of  values  for  all  the 
issues  as  identified  by  both  parties.  For 
example,  the  U.S.  may  not  be  willing  to  sign  a 
treaty  unless  it  spans  a  minimum  of  10  years, 
whereas  the  host  country  may  want  to  restrict  the 
duration  to  5  years.  It  can  be  inferred  that  the 
negotiation  will  encompass  the  period  between  5- 
10  years.  A  utility  curve  can  be  drawn  for 
different  values  between  the  5-10  year  range. 


Figure  2  shows  the  utility  curves  for  duration, 
jurisdiction  and  compensation  for  the  two 
countries.  Note  that  the.se  curves  are  unweighted 
in  that  they  do  not  take  into  consideration  the 
relative  weights  on  the  issues  described  in  step  3. 

Step  5.  For  each  party,  assign  relative  weights  to 
utility  curves.  This  is  done  by  taking  the 
product  of  the  utility  values  (vertical  axes  of  the 
graphs  in  Figure  2)  and  the  respective  relative 
weights  of  the  issues. 

Step  6  For  each  issue,  compute  the  joint  utility 
curve  by  adding  the  utility  functions  of  the  two 
countries. 

Step  7.  Detemiine  the  total  utility  for  each  nation 
across  all  the  issues.  Using  the  maximum  utility 
principle,  the  value  of  an  issue  is  the  highest 
point  on  the  joint  utility  curve.  For  the  first 
iteration,  llic  data  shown  in  Figure  2  yield  to  a 
total  utility  of  65  for  the  host  countrv  and  30  for 
the  U.S. 

As  the  outcomes  suggest,  it  is  imperative 
to  look  for  a  better  distribution  of  utility  points. 
For  this  situation,  as  shown  in  Figure  3,  the 
proposed  NSS  would  check  for  non-cooperative 
issues  and  calls  for  restructuring  A  cooperative 
situation  is  one  in  which  the  highest  value  of  the 
joint  utility  curve  is  higher  than  the  individual 
maximum  utility  values  of  both  parties. 
Conversely,  a  non-cooperative  situation  is  one  in 
which  the  highest  value  of  the  joint  utility  curve 
corresponds  to  the  highest  for  only  one  of  the 
parties,  leading  to  the  standard  zero-sum  game 
scenario.  In  this  circumstance,  it  is 
recommended  to  split  the  single  non-cooperative 
issue  into  subsets  of  more  asymmetrical  issues 
for  further  search  for  higher  Pareto  optima.  Note 
that  there  exists  other  aggregation  to  determine 
the  total  utility  for  both  parties,  e.g.,  mid-point 
analysis,  equal  utilities,  etc. 

The  model  as  described  in  this  section 
requires  perfect  information  and  is  very  sensitive 
to  perturbations  (e.g.,  falsification  of  weights  or 
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nos r COUNTRY 


UNIT  ED  STATUS 


<  DURATION  > 


<  JURISDICTION  > 


<  ECONOMIC  COMPENSATION  > 

Figure  2.  An  Example  of  Multi-Attribute  Utility  Function 
(adapted  from  1 1 )) 
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DEFINE  TREATIES 


Figure  3.  An  Interactive  Procedure  for  Bilateral  Negotiation 
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unilateral  disclosure  of  true  preferences  i  For  the 
safe  of  space,  these  issues  arc  not  discussed 
further,  although  they  could  be  resolved  by  a 
careful  and  ordered  preparation  of  the  negotiation 
process. 

5.  Fuzziness  in  Preference  Formulation 

Experience  has  shown  that  it  is  difficult 
for  the  negotiators  to  define  precisely  their  utility 
functions  for  the  issues  (Step  Negotiators 
might  not  understand  the  precise  meaning  of  the 
utility  scale  (e  g.,  O-KKf  in  the  example).  Yet. 
they  arc  forced  to  provide  ensp  inputs  for  the 
utilities  Human  quantification  is  fuzzy  at  best, 
and  a  narrow  range  of  acceptable  values  might 
exist  around  the  crisp  utility  value  suggested  by 
the  negotiator.  Zimmermann  (1987)  asserts  that 
under  such  circumstances,  using  fuzzy  sets  can 
capture  tlic  uncertainty  or  vagueness  of  the 
negotiators  better. 

A  fuzzy  set  contains  one  or  more  pairs 
of  numbers.  The  first  of  each  pair  represents  a 
dc'main  element.  In  this  negotiation  context,  the 
domain  element  is  the  utility  values  [O.IOO]  with 
respect  to  the  issue  range.  The  second  element 
in  the  pair  is  the  degree  of  membership  of  lliat 
element  in  die  fuzzy  set  ranging  from  |0,l| 
(Norwich  &  Turksen,  1984).  For  example,  the 
fuzzy  set  for  a  scale  response  80  (on  a  0-100 
utility  scale)  would  contain  80  with  certainty 
(i.c ,  membership  valuc=l)  and  the  other 
proximate  values  (e  g..  70,  75.  85,  90)  with 
lesser  degrees  of  membership  (e.g.,  0.4,  0.8.  0.9, 
0.75). 

Through  the  u.se  of  fuzzy  sets  for  each 
scale  response  to  create  the  utility  function, 
vagueness  or  complexity  in  the  input  information 
can  be  captured.  Instead  of  eliciting  the  utilities 
of  the  negotiators  with  regard  to  the  issues 
directly  by  a.sking  them  to  provide  a  cri.sp 
definition  of  their  utility  curves,  the  fuzzy  sets 
approach  attempts  to  seize  the  uncertainty  from 
the  negotiators  inputs  and  reconstruct  their  utility 


functions.  The  utility  value  can  be  reconstructed 
by  using  the  weighted  sum. 

6.  An  Example  of  Formulating 
Fuzzy  Preference 

In  the  NSS  using  fuzzy  set  technique, 
the  preference  elicitation  is  achieved  as  follows. 
For  a  specific  value  of  a  given  issue,  die  user  is 
prompted  for  a  utility  value.  The  utility  value  is 
assigned  to  be  the  domain  element  associated 
with  a  membership  value  of  1.  If  the  user 
indicates  that  there  exists  other  domain  elements 
having  positive  membership  values,  the  system 
prompts  the  user  for  membership  values  for 
proximate  utilities  (for  example,  values  ranging 
10  points  around  the  initial  domain  value 
whenever  possible).  The  set  of  utilities  widi 
their  memberships  for  a  given  issue  value  is 
referred  to  as  a  fuzzy  function. 

Let  us  say  after  elicitation,  the  fuzzy 
function  for  a  treaty  of  10  year  duration  for  the 
U.S.  looks  as  follows:  f(juration^’^  = 

((70.0.4).  (75,0.8),  (80,1),  (85,0.9),  (90,0,75)]. 
We  arrive  at  a  single  utility  value  for  duration  of 
10  using  die  weighting  scheme  mentioned 
earlier.  (70*0,4  +  75*0.8  +  80*1  +  85*0.9  + 
90*0.75)  /  (0,4  +  0.8  -r  1  -I-  0.9  +  0.75)  =  81. 

The  procedure  is  then  rci:)eatcd  for  other 
possible  values  of  the  duration  issue.  The 
resulting  set  of  utility  points  are  then  used  to 
specify  the  utility  function.  The  utility  functioas 
of  other  issues  can  also  be  done  in  a  similar 
manner. 


7.  Summary 

To  use  a  formal  muld-attribute 
negotiation  model,  negotiators  are  supposed  to 
provide  consistent  and  stable  preference 
information.  This  information  should  not 
contradict  with  previous  judgments.  The 
interactive  procedure  proposed  in  this  paper 
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seeks  to  allow  the  negotiators  to  strengthen  their 
preference  structure.  This  can  be  achieved 
through  an  interactive  exploration  of  the  fu77> 
sets.  We  expect  that  true  preferences  will  nnally 
emerge  from  the  learning  process  made  pos.vil  w 
by  the  system.  The  algorithm  discussed  in  this 
paper  is  a  specific  treatment  of  preference 
information.  Funher  research  is  required  to 
explore  better  elicitation  of  preference 
information. 
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APPENDIX  B 


DOD  STANDARD  7935A  END  USER  MANTAL  GUIDELINES 

The  End  User  Manual  is  a  vital  reference  source  for  the  functional  user  of  an 
application.  It  must  contain  an  overview  of  the  application  package  as  w'ell  as  an 
explanation  of  all  of  the  instructions,  formats  and  procedures  by  which  the  functional 
users  can  utilize  the  system. 

1.  OBJECTIVES 

The  manual  should,  as  a  minimum,  meet  the  following  objectives; 

1 . 1  Acquaint  new  users  of  the  application  package  with  its  features  and  purposes. 

1.2  Show  new  users  how  to  perform  tasks  utilizing  the  application  package. 

a.  Prox  ide  a  quick,  easy  reference  for  all  users. 

b.  Describe  the  menu  format  of  the  application  package  to  help  the  user  to 
navigate  through  the  system. 

c.  Help  the  user  determine  which  online  screens  relate  to  forms  used 
on-the-job  for  the  business  process. 

d.  Enable  the  user  to  use  all  entry 'update/display  screens  related  to  tasks 
performed  on-the-job. 

2.  MANU  AL  ORGANIZATION 

The  manual  should  contain  major  topics,  such  as: 

2. 1  General  Information  -  The  purpose  of  the  End  User  Manual  and  of  the  system, 
reference  materials,  terms  and  abbreviations,  and  security. 

2.2  An  Overview  of  the  System  -  The  hardware  and  software  required, 
contingencies  and  alternate  modes  of  operation,  and  reporting 
problems. 
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2.3  Getting  Started  -  How  to  gain  access  to  the  system,  logon  requirements, 
other  user  authorization  requirements,  special  commands,  and  function  keys. 

2.4  Business  Processes  -  How  to  use  all  transactions  required  in  the  performance 
of  the  tasks  of  the  business  process.  How  to  find  and  retrieve  information  in 
the  Database  and/or  manual  files.  Data  backup,  error  messages,  recovery  from 
errors  and  malfunctions,  and  sample  reports  (hard  copy  and  online). 

The  Department  of  Defence  (DoD)  provides  guidelines  for  the  development  of 
documentation.  As  a  branch  of  DoD,  and  because  of  the  nature  of  the  Information 
Engineering  program  at  the  U.S.  Army  Corps  of  Engineers  (USAGE),  Application 
Development  Projects  should  adhere  to  this  documentation  standard  know  n  as  DoD-STD- 
7935  A. 

DoD-STD-7935A  lists  two  types  of  User  Manuals  that  may  be  produced  during  the 
life  cycle  of  an  Automated  Information  System  (AIS); 

•  Users  Manual 

•  End  User  Manual 

The  Users  Manual  is  a  high  level,  nontechnical  overs’iew  of  a  specific  AIS 
application  and  its  use  in  the  business  process.  Refer  to  the  Standard  for  further 
description. 

The  End  User  Manual  provides  detailed  information  necessary  to  enable  the 
functional  user  to  effectively  use  the  system.  The  emphasis  in  this  app>endix  is  on  the 
End  User  Manual.  The  following  is  the  formal  structure  specified  in  DoD-STD-7935A: 
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DoD-STD-7935A 


SECTION  1. 
1.1 
1.2 

1.3 

1.4 

1.5 

SECTION  2. 
2.1 
2.1.1 
2.1.2 

2.1.3 
2.2 
2.2.1 
2.2.2 

2.3 

2.4 

SECTION  3. 

3.1 

3.1.1 

3.1.2 

3.1.3 

3.2 

3.3 

SECTION  4. 

4.1 

4.2 

4.3 

4.3.1 

4.3.2 

4.4 

4.5 

4.6 


END  USER  MANX  AL 
TABLE  OF  CONTENTS 

GENERAL 

Purpose  of  the  End  User  Manual 
Purpose  of  the  System 
References 

Terms  and  Abbreviations 
Security 

SYSTEM  SUMMARY 

Oversiew 

Application  Summary 

Performance 

Controls 

System  Environment 
Hardware  Required 
Software  Required 

Contingencies  and  Alternate  Modes  of  Operation 
Assistance  and  Problem  Reporting 

ACCESS  TO  THE  SYSTEM 

First-Time  Use  of  the  System 
Equipment  Familiarization 
Access  Control 
Installation  and  Setup 
Initiating  a  Session 
Stopping  and  Suspending  Work 

PROCESSING  REFERENCE  GUIDE 

Capabilities 
Conventions 
Processing  Procedures 
Variable  Title  (Identify) 

Variable  Title  (Identify) 

Related  Processing 

Recovery  from  Errors  and  Malfunctions 
Messages 


43 


3.  DEVELOPING  SECTIONS  OF  THE  ENT)  L'SER  MANUAL 


Like  all  dcKumentation  components  of  DoD-STD-7935A.  the  End  User  Manual  is 
a  structured  document  with  specific  information  to  be  included  under  each  numbered 
paragraph.  The  numbering  scheme,  the  contents  of  each  paragraph,  and  the  information 
contained  in  each  paragraph  is  strictly  laid  out  and  must  be  followed  to  conform  to  the 
Standard.  The  following  is  an  extraction  of  this  Standard.  If  documentation  developers 
are  unclear  about  the  nature  of  the  information  to  be  included  under  each  paragraph 
heading,  the  actual  DoD-STD-7935A  should  be  consulted  and  used  in  this  effort. 

You  will  notice  that  Sections  1  through  3  of  the  End  User  Manual,  Table  of 
Contents,  DoD-STD-7935A,  address  the  important  generalities  of  the  system  where  as 
Section  4,  Processing  Reference  Guide  provides  the  End  User  with  the  necessary 
processing  procedures  of  the  business  If  the  procedures  are  complicated  or  extensive, 
the  Standard  suggests  that  additional  sections  be  added  using  the  same  paragraph  structure 
as  in  Section  4. 


SECTION  1.  GENERAL 

1.1  PuTDose  of  the  End  User  Manual.  This  paragraph  describes  the  purpose  of  the  End 
User  Manual  either  in  the  following  words  or  modified  if  appropriate; 

"The  objective  of  the  End  User  Manual  for  (Project  Name)  (Project  Number)  is  to 
provide  the  end  user  with  the  information  necessary  to  use  the  system  effectively, 
including  operation  of  (identification  of  terminal  or  personal  computer)  equipment." 

1.2  Purpose  of  the  System.  This  paragraph  states  the  purpose  of  the  system,  the  specific 
objectives  to  accomplish  the  mission,  the  expected  benefits  and  the  major  functions  of 
the  application. 

1.3  References.  Identify  other  documents  which  the  end  user  may  need  in 
accomplishing  tasks  and  procedures.  Specify  the  name  of  the  document,  author  or 
source,  reference  number,  title,  date  and  security  classification,  if  any. 

a.  Project  Request.  Indicate  the  project  proponent  and  a  reference  to  the 
Structured  Requirements  Analysis  Planning  (STRAP)  report  or  other  documentation  that 
initiated  the  project. 

b.  Hardware  documentation  such  as  that  addressing  setup,  jwwerup  and 
powerdown,  packing  for  relocation,  activation  operation  or  maintenance. 
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c.  Software  documentation  of  an  operating  system,  utility  software  or  documents 
oriented  to  an  end  user  for  related  systems.  References  to  methodologies  could  be  listed 
in  this  section.  An  example ’s  the  IDEF  Modeling  Techniques  Workshop  Participant 
Workbook.  D.  Appleton  Company.  Inc..  1986,  1987  and  1988. 

d.  Previously  published  documentation  on  the  project  if  needed  for  accomplishing 
the  end  user's  tasks.  An  example  might  be  a  reference  to  the  Functional  Description  of 
the  project. 

1.4  Terms  and  Abbreviations.  Either  include  a  list  or  reference  an  appendix  of  terms, 
definitions  and  acronyms  unique  to  this  document. 

1.5  Security.  Under  this  paragraph,  an  of)ening  sentence  stating  that  precautions  have 
been  taken  to  protect  the  hardware,  software  and  data  of  the  system  (name).  Then  cite 
the  following  kinds  of  security  precautions  addressed: 

a.  Assignments  of  User  IDs  and  Passwords  to  access  the  hardware  and  any  user 
account  reporting  requirements. 

b.  Assignments  of  User  Names  and  Passwords  to  control  access  to  the  software. 
Describe  how  access  levels  vary.  For  instance,  you  may  want  to  indicate  that  access 
levels  vary,  depending  on  whether  the  user  is  restricted  to  search  and  retrieval  activities, 
data  entry,  interactive  retrieval  and  update  or  ad-hoc  queries  and  reports. 

c.  A  statement  of  how  data  integrity  is  assured,  and  how  error  checking /correcting 
procedures  and  data  backup  procedures  are  employed. 

d.  A  statement  to  the  affect  that  regulations  regarding  the  unauthorized  disclosure 
or  use  of  User  IDs,  User  Names  or  Passwords  are  to  be  applied  to  all  such  items 
assigned  to  the  user.  In  addition,  the  user  must  comply  with  all  privacy  requirements. 
Unauthorized  copying  of  data,  documents  or  software  is  prohibited. 
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SECTION  2.  SYSTEM  SUMMARY 


2.1  Overx  ieu  .  This  section  provides  a  nontechnical  presentation  of  information  on  the 
overall  system.  Detailed  technical  information  should  be  presented  in  other  sections. 

2.1.1  Application  Summary'.  This  paragraph  explains  the  uses  of  the  application 
and  the  user  activities  which  it  supports.  It  describes  the  main  functions  performed  by 
the  system  showing: 

a.  The  logical  parts  of  the  system  from  the  end  user  s  viewpoint. 

b.  The  communication'^  paths  and  techniques. 

c.  The  interfaces  to  other  systems. 

d.  The  organizations  that  provide  input  to  the  system  or  receive  output  from  it. 

2.1.2  Performance.  Describe  the  overall  system  performance  capabilities,  such 
as  times  and  capacits  constraints,  which  the  end  user  can  expect  in  accomplishing  major 
functions. 

2.1.3  Controls.  This  paragraph  briefly  describes  the  supervisory  controls 
necessary  to  manage  or  audit  the  system. 

2.2  System  Environment.  This  paragraph  describes  the  configuration  of  the  hardw-are 
and  software  necessary  to  support  the  system.  An  overview  of  the  host  or  LAN 
configuration  is  provided,  but  more  detail  is  needed  for  workstation  configurations. 

2.2.1  Hardware  Required.  This  paragraph  identifies  and  describes  the  hardware 
required  to  run  the  system. 

2.2.2  Software  Required.  This  paragraph  identifies  and  discusses  software 
capabilities  necessary  to  use  the  system.  It  includes  software  components  developed  for 
the  application  as  well  as  the  operating  system,  utilities  and  other  supporting  systems. 

2.3  Contingencies  and  Alternate  Modes  of  Operation.  This  paragraph  includes  a 
statement  as  to  what  the  user  may  expect  in  systems  operations  during  emergencies, 
wartime  or  conditions  of  alert. 

2.4  Assistance  and  Problem  Reporting.  This  section  describes  online  or  manual  help 
features,  and  identifies  points  of  contact  or  other  resources  and  procedures  to  assist  the 
user  when  problems  are  encountered. 
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SECTION  3.  ACCESS  TO  THE  SYSTEM 


3. 1  First-Time  Use  of  the  System,  This  section  is  intended  to  describe  detailed  step-by- 
step  procedures  oriented  to  the  first-time/occasional  end  user.  Enough  detail  should  be 
presented  so  that  the  end  user  can  reliably  access  the  system  even  before  learning  the 
details  of  its  functional  capabilities. 

3.1.1  Equipment  Familiarization.  This  paragraph  describes  the  following  kinds 
of  features,  as  appropriate: 

a.  Procedures  for  turning  power  on  and  making  any  adjustments. 

b.  Visual  display  screen  capabilities. 

c.  How  to  identify,  position  and  use  the  cursor. 

d.  Keyboard  layout,  function  keys,  and  pointing  devices  such  as  a  mouse. 

e.  Procedures  for  turning  power  off  and  any  special  sequencing  operations 
required. 

3.1.2  Access  Control.  This  paragraph  gives  an  overview  of  system  access  and 
security  features  visible  to  the  end  user,  such  as: 

a.  How  to  obtain  a  password;  who  to  contact:  which  form  to  submit. 

b.  How  the  user  can  change,  add  or  delete  a  password. 

c.  Confidentiality  -  security  and  privacy  considerations  regarding  storage  and 
various  output  media  generated  by  the  end  user. 

3.1.3  Installation  and  Setup.  This  paragraph  shall  describe  any  special  procedures 
which  the  end  user  must  perform  in  order  to  be  identified  or  authorized  to  access  or 
install  software  on  the  equipment,  or  to  enter  parameters  for  AIS  operation. 

3.2  Initiating  a  Session.  This  paragraph  provides  the  end  user  with  step-by-step 
procedures  on  how  to  begin  work.  Also  include  a  problem  checklist  for  difficulties 
encountered. 

3.3  Stopping  and  Suspending  Work.  This  section  describes  how  the  user  can  interrupt 
or  stop  the  system. 


47 


ECTION 


4. 


PROCESSING  REFERENCE  GUIDE 


This  section  shall  provide  the  end  user  with  technical  information  on  processing. 
DoD-STD-7935A  advises  that  if  the  procedures  are  complicated  or  extensive,  additional 
sections  5,  6,  ...  may  be  added  using  the  same  paragraph  structure  as  used  in  section  4. 
The  Standard  states  on  page  88  that  the  organization  of  the  document  will  depend  on  the 
characteristics  of  the  AIS  being  documented.  For  example,  if  the  tasks  of  end  users  vary 
depending  upon  the  organization  echelon  in  which  they  work.  Section  4  might  be  oriented 
to  headquarters  functions  and  Section  5  to  remote  site  functions. 


SECTION  4.  PROCESSING  REFERENCE  GUIDE  MENUS  USED  IN  THE 
SYSTEM 


4.1  Capabilities.  This  paragraph  provides  an  overvie\v  of  the  use  of  the  system 
describing  menus,  functions,  transactions  and  their  interrelationships. 

4.2  Conventions.  This  paragraph  describes  the  conventions  used,  such  as  rules  for 
assigning  names  or  codes,  abbreviations,  colors  on  the  screens  and  use  of  audible  alarms. 

4.3  Processing  Procedures  -  MENUS 

NOTE:  Detailed  procedures  are  intended  to  be  presented  in  the  subparagraphs  of 
paragraph  4.3.  Depending  on  the  design  of  the  AIS,  the  subparagraphs  might  be 
organized  on  a  function-by-function  basis  or  on  a  menu-by-menu  basis.  For  a 
transaction-oriented  system  the  organization  might  be  on  a  screen-by-screen  basis. 

4.3.1  Variable  Title  (Identify).  The  title  of  this  paragraph  shall  identify  the 
function,  menu,  transaction  or  other  process  being  described.  This  paragraph  shall 
describe  and  give  examples  of  menus,  data  entry  forms,  outputs,  diagnostic  messages  or 
alarms  and  help  facilities  which  can  provide  online  descriptive  or  tutorial  information. 
The  format  for  presenting  this  information  can  be  adapted  to  the  particular  characteristics 
of  the  AIS,  but  a  consistent  style  of  presentation  must  be  used,  i.e.,  the  descriptions  of 
menus  must  be  consistent,  the  descriptions  of  transactions  must  be  consistent  among 
themselves. 


4.3.2  Variable  Title  (Identify).  This  paragraph  shall  describe  the  second  function, 
menu  or  other  procedure  using  the  same  format  for  information  as  used  in  paragraph 
4.3.1.  Additional  functions,  menus  or  other  procedures  should  be  described  in 
paragraphs  4.3.3  through  4.3.n. 

4.4  Related  Processing.  This  paragraph  shall  identify  and  describe  any  related  batch, 
offline  or  background  processing  performed  by  the  AIS  that  is  not  invoked  directly  by 
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the  end  user  and  is  not  described  in  paragraph  4.3.  Any  end  user  responsibilities  to 
sup]X)rt  this  processing  will  be  specified. 

4.5  Recovers'  from  Errors  and  Malfunctions.  This  paragraph  shall  describe 
responsibilities  of  the  end  user  for  making  and  retaining  all  recorded  data  which  can  be 
used  to  replace  primary  copies  of  data  in  event  of  errors,  defects,  malfunctions  or 
accidents.  Step-by-step  procedures  shall  be  described  as  necessary. 

4.6  Messages.  This  paragraph  shall  list,  or  refer  to  an  appendix  w'hich  lists  all  error 
messages,  diagnostic  messages  and  information  messages  which  can  occur  while 
accomplishing  any  of  the  end  user's  functions  described  in  paragraphs  4.3  through  4.6. 
The  normal  corrective  action  that  should  be  taken  after  any  such  message  should  be 
identified  and  described. 

Continuing  with  this  example,  section  5  would  be  as  follows: 

SECTION  PROCESSING  REFERENCE  GUIDE  -  COMMAND  LANGUAGE 
USED  IN  SV.STEM 


Then  the  same  paragraph  structure  as  section  4  would  be  followed  for  items  5.1  through 
5.6: 

5.1  Capabilities. 

5.2  Conventions. 

5.3  Processing  Procedures  -  COMM.AND  LANGUAGE 

etc . 

SECTION  6.  PROCESSING  REFERENCE  GUIDE  -  GUIDE  TO  FUNCTIONS 

6.1  CapTbilities. 

6.2  Conventions. 

6.3  Processing  Procedures  -  FUNCTIONS 

etc . 
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4.  MANUAL  PREPARATION 


There  are  two  distinct  stages  in  preparing  the  End  User  Manual: 

1.  A  Draft  End  User  Manual  is  prepared  for  the  Alpha  Test  of  the 
application  developed. 

2.  An  Integrated  End  User  Manual  is  compiled  for  the  Beta  Test  and 
Deployment. 

Draft  documentation  should  evolve  throughout  the  INTERACTIVE- 
APPLICATION-DEVELOPMENT  activity.  As  each  component  of  the  application  is 
completed  and  unit  tested,  an  application  developer  or  documentation  specialist  prepares 
draft  documentation  for  peer  reviews.  If  the  application  developed  is  complex  with  a 
fairly  large  number  of  people  performing  narrow  sets  of  functions,  it  may  be  practical 
to  issue  separate  sections  of  the  manual  for  each  type  of  user  (e.g.,  administrative, 
engineers,  project  managers,  etc.).  This  documentation  is  updated  and  consolidated  for 
the  Alpha  Test.  Copies  of  the  Draft  End  User  Manual  are  made  for  the  Alpha  Test 
Team,  the  IPR  Team,  the  Development  Team  and  other  interested  parties.  It  is  not  a 
formal  publication. 

Following  the  Alpha  Test,  corrections  and  various  required  modifications  are  made 
to  produce  an  End  User  Manual  for  the  Beta  Test.  The  Beta  Test  will  be  testing  the  end 
user  documentation  as  well  as  the  application  itself. 

If  the  application  developed  is  an  extension  or  additional  enhancement  of  a  previous 
project,  an  Integrated  End  User  Manual  is  compiled  following  the  Alpha  Test.  Since  the 
Beta  Test  is  for  a  "live"  environment,  existing  documentation  for  the  business  process 
should  be  integrated  with  the  new  documentation. 

5.  PACKAGLNG  OF  THE  ENT)  USER  MANX  AL 

The  End  User  Manual  should  be  a  3-ring  binder  type,  with  divider  tabs  for  all 
major  sections  and  appendices. 

6.  MAINTENANCE  OF  END  USER  MANUAL 

The  creation  and  maintenance  of  the  End  User  Manual  should  be  the  responsibility 
of  the  Application  Development  Team  until  transition  of  the  application  to  the  support 
group  for  deployment.  At  this  time,  maintenance  responsibilities  should  be  transferred 
to  the  support  agency. 
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APPENDIX  C 


BILATERAL  NSS  USER  MANU  AL 

Section  1,  General 

1.1  Purpose  of  the  End  User  Manual.  The  objective  of  the  End  User  Manual  for 
the  Bilateral  Negotiation  Support  System  (NSS)  is  to  provide  the  end  user  with  the 
information  necessary  to  use  the  system  effectively,  including  operation  under  the 
Microsoft  Windows  3.0  environment. 

1.2  Purpo.se  of  the  System.  The  purpose  of  the  Bilateral  NSS  is  to  assist  one  or 
two  negotiators  in  achieving  an  equitable  solution  to  a  negotiation  problem.  Each 
negotiation  session  allows  the  user  to  enter  issues,  weights  and  utilities  associated  with 
each  issue.  After  receiving  inputs  from  both  negotiators,  the  program  will  calculate  and 
display  the  results  in  both  tabular  and  graphical  formats.  Users  also  can  modify  any 
input  variables  and  perform  "what-if  analysis  to  see  any  effects  on  the  final  results. 

1.3  References.  Further  information  on  NSS  theory  and  W'indows  3.0  operation 
may  be  obtained  from: 

a.  Bui,  T.  and  Sivasankaran,  T.,  "Fuzzy  Preferences  in  Bilateral  Negotiation 
Support  Systems",  24th  Annual  Hawaii  International  Conference  on  System  Sciences, 
January  8-11,  1991,  pp.  687-694,  IEEE  Computer  Society  Press. 

b.  Bui,  T.,  Co-op:  A  Group  Decision  Support  System  for  Cooperative 
Multiple  Criteria  Group  Decision-Making,  Springer- Verlag,  Berlin,  1987. 
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c.  Microsoft  Windows  User's  Guide,  version  3.0.  Microsoft  Corporation, 

K>^0. 

1.4  Terms  and  Abbreviations.  All  terms  and  abbreviations  unique  to  the  Bilateral 
NSS  are  explained  in  the  applicable  sections  of  the  manual.  Additional  Windows  3.0 
terminology  may  be  obtained  from  the  glossary  section  of  the  Windows  User's  Guide. 

1.5  Security.  Password  protection  is  provided  for  all  user  sensitive  information. 
The  5  character  password  is  non-modifiable  once  entered.  A  dialog  box  requesting  user 
confirmation  is  presented  for  all  operations  that  would  overwrite  any  existing  files. 

Section  2.  System  Summary 

2.1  Overview.  The  Bilateral  NSS  is  a  software  program  based  on  multiple 
attribute  utility  theory  and  the  concept  of  joint  utility.  Although  not  required,  the 
following  procedure  is  normally  used  to  operate  the  program: 

a.  Identify  a  common  set  of  issues  about  which  the  parties  disagree. 

b.  Define  the  range  of  values  for  each  issue  by  assigning  initial  offers. 

c.  Prioritize  each  issue  by  assigning  relative  weights  to  them. 

d.  Within  the  range  of  values  for  each  issue  assign  utility  values. 

e.  Compute  joint  utility  curves  by  combining  the  utility  functions  of  each 

party. 

f.  Observe  negotiation  results  and  modify  user  variables  to  search  for  better 
solutions. 
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2.2  System  Environment. 


2.2.1  Hardware  Required.  This  program  will  operate  on  any  IBM 
compatible  PC  with  at  least  640K  of  Random  Access  Memory  (RAM).  A  hard  disk  is 
not  required. 

2.2.2  Software  Required.  This  program  requires  DOS  3.1  or  higher  and  the 
Microsoft  Windows  3.0  operating  system  to  run.  Additionally,  two  dynamic  link 
libraries  (DLL)  called  VBRUN100.DLL  and  VBTOOLS.VBX  must  be  located  in  any 
directory  in  your  path. 

2.3  Contingencies  and  Alternate  Modes  of  Operation.  N/A 

2.4  Assistance  and  Problem  Reporting.  An  on-line  help  system  is  available  at  all 
times.  To  bring  up  the  main  help  screen  select  the  Index  command  from  the  Help  menu 
on  the  main  screen.  The  main  help  screen  contains  help  on  ten  subject  areas.  Select  the 
button  to  the  left  of  the  subject  area  that  you  want  help  on  and  press  the  Get  Help  button. 

To  get  context  sensitive  help  during  the  program  just  press  the  "?”  button  on  the 
bottom  right  comer  of  any  screen. 

Section  3.  Access  to  the  System 

3.1  First-Time  Use  of  the  System.  Follow  the  steps  below  to  start  the  program: 
a.  From  the  Windows  Program  Manager  screen  select  the  Run  command 
under  the  File  Menu. 
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b.  Tyf)e  "nss"  in  the  text  box  provided  if  the  nss.exe  file  is  in  your  path. 
If  nss.exe  is  not  in  your  path  then  you  must  type  in  the  entire  pathname.  Press  Enter  and 
the  Bilateral  NSS  opening  screen  will  appear. 

c.  If  you  want  help  with  the  program  before  starting,  simply  select  the  Index 
command  under  the  Help  Menu.  A  help  screen  will  appear  with  instructions  on  how  to 
use  the  program. 

d.  To  begin  a  new  negotiation  session,  follow  the  steps  in  paragraph  3.2 
below.  On-line  help  is  available  at  all  times  by  selecting  the  "?"  button  located  at  the 
bottom  of  each  screen. 

3.2  Initiating  a  Session.  Follow  the  steps  below  to  start  a  new  negotiation  session: 

a.  Select  the  Start  Nev\  Session  command  under  the  File  Menu. 

b.  Type  a  filename  (up  to  8  characters)  to  save  your  work  under  then  press 
the  OK  button. 

c.  Enter  your  name,  party  and  a  5  character  password  in  the  spaces 
provided.  Don't  forget  your  password  since  once  it  is  entered  it  cannot  be  changed. 
Press  the  OK  button  to  continue. 

d.  The  Main  Selection  Menu  will  appear  with  the  top  two  options  available. 
The  last  three  options  are  not  available  (shown  as  grayed  out  text)  until  both  parties  have 
entered  initial  starting  offers  for  each  issue.  Select  the  Issue  Parameters  option  and  press 
the  OK  button  to  continue. 

e.  The  Issue  Parameters  screen  has  three  entries  for  each  issue  -  Issue 
Name,  Unit  Value  and  Initial  Starting  Offer.  Issue  names  can  be  up  to  15  characters 
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long  The  Unit  V'aJue  (up  to  7  characters)  is  the  unit  of  measure  for  an  issue  —  e.g., 
dollars,  years,  etc.  Initial  starting  offers  (0  to  30000)  can  be  entered  directly  into  the 
text  box  or  selected  by  using  the  scroll  bars  beside  each  issue. 

f.  To  add  a  new  issue  just  press  the  Add  New  Issue  button  at  the  bottom  of 
the  screen.  Likewise,  to  delete  an  issue  press  the  Delete  Issue  button  and  enter  the 
number  of  the  issue  you  want  to  delete.  Once  you  are  done  press  the  OK  button  to 
accept  your  entries. 

g.  Once  both  parties  have  entered  initial  starting  offers  the  last  three  options 
on  the  Main  Selection  Menu  will  be  available.  Select  the  Issue  Priority  option  and  press 
the  OK  button.  At  this  point  a  password  screen  will  appear  asking  you  to  enter  your 
password.  Type  in  your  character  password  and  press  Enter  (the  program  is  case 
sensitive  so  capitalize  any  letters  you  did  when  you  initially  entered  it). 

h.  The  next  screen  gives  you  three  choices  for  ranking  each  issue  --  equal 
weighting,  direct  prioritization  and  pairwise  comparison.  Select  your  choice  and  follow 
the  instructions.  After  completing  your  rankings  you  will  be  returned  to  the  Main 
Selection  Menu. 

i.  Select  the  Utility  Values  option  and  press  the  OK  button.  You  will  again 
be  requested  to  enter  your  password. 

J.  The  Utility  Value  screen  lists  all  session  issues  on  the  left  side  and  the 
seven  utility  values  for  the  currently  active  issue  on  the  right  side.  To  enter  utility  values 
follow  this  procedure: 

1 .  Click  the  option  button  to  the  left  of  any  issue  you  want  to  update. 


2.  At  the  bottom  of  the  utility  graph  are  the  seven  range  points  for  that 
issue.  Above  each  range  point  is  a  column  of  utility  values  from  0  to  100.  Select  a 
utility  value  for  each  range  f)oint  (0  being  no  utility  and  100  being  maximum  utility). 

3.  Repeat  steps  1  and  2  for  each  issue.  Press  the  OK  button  to  accept 
your  data  and  return  to  the  Main  Selection  Menu. 

k.  To  view  the  results  of  the  negotiation  at  this  point  select  the  Negotiation 
Results  option  and  press  the  OK  button.  The  Negotiation  Results  screen  will  appear. 

l.  The  Negotiation  Results  screen  displays  three  sets  of  tabular  data  -  highest 
joint  utility,  mid-point  utility  and  relative  importance  utility.  Additionally,  there  is  a 
Scratch  Pad  that  allows  you  to  enter  any  range  point  (the  green  Descriptor  column)  to 
observe  how  the  individual  pany  and  total  utility  values  will  be  affected. 

m.  To  print  out  the  results  on  the  screen  press  the  Print  button.  To  save  the 
screen  results  as  an  ASCII  text  file  press  the  Save  button.  To  view  the  results 
graphically  press  the  Display  Graphs  button  at  the  bottom  of  the  screen. 

n.  The  Graphs  screen  allows  you  to  view  the  weighted  or  unweighted  results 
of  any  issue.  Just  select  the  issue  from  the  list  at  the  left  of  the  screen  and  select  either 
the  Weighted  or  Unweighted  option  button  below  it. 

o.  To  quit  the  current  session  and  save  your  work  just  press  the  Quit  button 
on  the  Main  Selection  Menu  and  follow  the  instructions. 

3.3  Stopping  and  Suspending  Work.  You  may  quit  the  current  session  you  are 
working  on  at  any  point.  If  you  are  in  the  middle  of  entering  data  press  the  OK  button 
for  that  screen  if  you  want  to  update  those  entries.  After  returning  to  the  Main  Selection 
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Menu  press  the  Quit  button  and  a  Save  screen  will  appear.  If  you  want  to  save  your 
newly  entered  data  and  overwrite  the  old  file  just  press  the  Save  button.  Otherwise, 
press  the  Cancel  button.  At  this  point  you  can  start  a  new  session  or  open  a  prior  one. 

To  save  your  work  without  going  through  the  Main  Selection  Menu  just  select  the 
File  Menu  on  the  Bilateral  NSS  main  screen  and  select  the  Save  or  Save  As  commands. 
The  Save  command  will  allow  you  to  save  your  data  under  the  current  session  name  and 
Save  As  will  let  you  save  your  data  under  any  filename. 

To  quit  the  Bilateral  NSS  program  select  the  Exit  Program  command  under  the  File 
Menu  and  follow  the  prompts. 

Section  4.  Processing  Reference  Guide  -  Menus 

4.1  Processing  Procedures  -  Menus.  There  are  two  menus  associated  with  the 
opening  Bilateral  NSS  screen  --  File  and  Help. 

4.1.1  File  Menu.  There  are  five  commands  under  the  File  Menu: 

4. 1.1.1  Start  New  Session.  This  command  is  selected  to  start  a  new 
negotiation  session.  A  dialog  box  will  appear  requesting  a  filename  to  save  your  data 
under. 

4. 1.1. 2  Open  Prior  Session.  This  command  is  selected  to  open  a 
previous  negotiation  session.  A  dialog  box  will  appear  that  allows  you  to  browse  through 
any  drive  and  directory  for  a  prior  session’s  data.  Only  filenames  with  a  .nss  extension 
will  be  shown  in  the  file  list  box. 

4.1 .1.3  Save  Current  Session.  This  command  is  selected  to  save  the 
current  negotiation  data  under  the  currently  active  filename.  A  dialog  box  will  appear 
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that  asks  you  if  you  want  to  save  the  data  under  the  current  name.  Select  Save  to  store 
the  data  or  Cancel  to  abort  the  command. 

4. 1  ■  1 .4  Save  Current  Session  As.  This  command  is  selected  to  save  the 
current  negotiation  data  under  any  user  entered  filename.  A  dialog  box  will  appear  that 
allows  you  to  enter  any  filename  up  to  8  characters  long.  Select  Save  to  store  the  data 
or  Cancel  to  abort  the  command 

4, 1 . 1 ,5  Exit  Program.  This  command  is  selected  to  end  the  Bilateral 
NSS  program.  A  dialog  box  will  appear  that  allows  you  to  save  the  current  negotiation 
data  under  the  currently  active  filename.  Select  Save  to  exit  the  program  after  saving  the 
latest  negotiation  data  or  Cancel  to  exit  the  program  without  saving  the  latest  data. 
4.1.2  Help  Menu.  There  are  two  commands  under  the  Help  Menu: 

4. 1.2.1  Index.  This  command  is  selected  to  bring  up  the  main  help 
menu.  A  screen  will  appear  that  explains  the  help  system  and  allows  the  user  to  select 
from  a  menu  of  ten  subject  areas. 

4. 1.2.2  About...  This  command  brings  up  the  Bilateral  NSS  credit 

screen. 

Section  5.  Processing  Reference  Guide  -  Procedures 

5. 1  Starting  a  New  Negotiation  Session.  To  begin  a  new  session  select  the  Start 
New  Session  command  under  the  File  Menu  and  follow  the  procedures  below; 

a.  Enter  any  filename  up  to  8  characters  in  the  text  box  provided.  Press  the 
OK  button  to  continue. 


58 


b.  Next,  enter  your  name,  party  and  a  5  character  password  in  the  textboxes 
provided.  Don’t  forget  your  password  since  once  it  is  entered  you  can’t  change  it.  Press 
the  OK  button  to  continue. 

c.  When  the  Main  Selection  Menu  is  displayed  select  the  Issue  Parameters 
option  and  press  the  OK  button. 

d.  Enter  up  to  10  issues  and  an  initial  starting  value  using  the  scroll  bars 
next  to  each  issue.  A  ne\\  issue  may  be  added  by  clicking  on  the  Add  Nev\  Issue  button 
at  the  bottom  of  the  screen.  To  delete  an  issue  click  on  the  Delete  Issue  button. 

e.  Once  both  panics  have  entered  initial  starting  values  you  can  enter  your 
weightings  and  utilities  by  selecting  the  appropriate  option  from  the  Main  Selection 
Menu. 

f.  Selecting  the  Negotiation  Results  option  from  the  Main  Selection  Menu 
will  give  you  a  tabular  display  of  the  results  of  the  current  session.  Clicking  on  the 
Display  Graphs  button  at  the  bottom  of  the  screen  will  display  the  issues  in  graphical 
form. 

5.2  Opening  a  Prior  Negotiation  Session.  To  open  a  prior  negotiation  session 
select  the  Open  Prior  Session  command  from  the  File  Menu  and  follow  the  procedures 
below" 

a.  A  dialog  box  will  appear  with  three  list  boxes  to  let  you  select  which 
drive  or  directory  to  search  in.  Double  clicking  on  a  directory  in  the  directory  list  box 
will  make  that  your  default  directory.  Only  filenames  with  a  .nss  extension  will  be 
shown. 
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b.  To  select  a  file  either  double  click  on  the  filename  or  press  the  OK  button 
after  clicking  once  on  the  filename. 

c.  After  selecting  the  file,  the  Main  Selection  Menu  will  appear.  You  can 
then  select  any  option  that  is  not  grayed  out. 

5.3  Saving  a  Negotiation  Session.  To  save  a  negotiation  session  select  the  Save 
Current  Session  command  under  the  File  Menu  and  follow  the  procedures  below; 

a.  A  dialog  box  will  appear  asking  you  whether  you  want  to  save  the  current 
data  using  the  filename  you  entered  when  you  started  the  session. 

b.  Press  the  OK  button  to  save  your  data  or  press  the  Cancel  button  to  retum 
to  the  previous  screen.  Remember  that  selecting  OK  will  overwrite  any  previous  data 
you  may  have  stored  in  that  file. 

5.4  Saving  a  Negotiation  Session  Under  a  Difterent  Name.  To  save  a  negotiation 
session  under  a  different  name  select  the  Save  Current  Session  As  command  under  the 
File  Menu  and  follow  the  procedures  below  ; 

a.  Enter  the  name  you  want  to  save  your  data  under  in  the  text  box  provided. 
A  filename  can  consist  of  any  combination  of  letters  and  numbers  up  to  eight  characters. 
The  filename  will  automatically  be  given  a  .nss  extension. 

b.  Press  the  Save  button  to  save  your  data  or  t!ie  Cancel  button  to  retum  to 
the  previous  screen.  Remember  that  selecting  Save  will  overwrite  any  previous  data  you 
may  have  stored  in  that  file. 

5.5  Using  the  Main  Selection  Menu.  There  are  five  selection  options  for  each 
party.  They  are; 
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a.  Issue  Parameters  -  this  option  allows  either  party  to  add  or  delete  issues. 
Initial  starting  offers  are  also  entered  on  this  screen. 

b.  Name  or  Party  -  this  option  allows  either  party  to  enter  or  change  their 
name  or  party  data.  If  this  is  the  party's  first  entry  for  the  session  they  will  also  enter 
a  five  character  password. 

c.  Issue  Priorities  -  this  option  allows  either  party  to  adjust  the  weighting 
given  to  each  issue, 

d.  Utility  Values  -  this  option  allows  either  party  to  enter  or  update  the 
utilities  assigned  to  each  issue. 

e.  Negotiation  Results  -  this  option  allows  either  party  to  view  the  results  of 
the  current  negotiation  session.  A  Scratch  Pad  is  provided  to  allow  a  party  to  perform 
"what-if"  analysis  on  the  results. 

1 .  Pressing  the  Display  Graphs  button  brings  up  a  screen  that  allow's  you 
to  view  the  results  in  graphical  form.  Both  weighted  and  unweighted  results  can  be 
viewed. 

2.  Pressing  the  Save  or  Print  buttons  will  send  the  negotiation  results  in 
ASCII  form  to  the  disk  or  printer,  respectively. 

5.6  Entering/Changing  Party  Data.  To  enter  or  change  party  data  select  the  Name 
or  Party  option  from  the  Main  Selection  Menu  and  follow  the  procedures  below: 

a.  If  you  are  entering  this  data  for  the  first  time  a  dialog  box  will  appear 
with  empty  textboxes  for  name,  party  and  password. 
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b.  Enter  up  to  15  characters  for  your  name  and  party.  Your  password  must 
be  five  characters  long  and  can  consist  of  any  combination  of  letters  and  numbers.  Don't 
forget  this  password  since  once  it  is  accepted  it  can  not  be  changed. 

c.  If  you  are  updating  previously  entered  information  a  dialog  box  requesting 
your  password  will  appear.  Enter  your  password  and  press  Enter. 

d.  Change  the  name  or  party  information  in  the  textboxes  provided  and  select 
OK  when  you  are  done. 

5.7  Entering  Issue  Parameters. 

a.  Three  types  of  data  are  entered  for  each  issue; 

1.  Issue  Name  -  (max.  of  15  characters) 

2.  Unit  Value  -  (max.  of  7  characters)  the  unit  of  value  that  describes 
the  issue.  For  example,  if  contract  length  was  an  issue,  then  the  unit  value  might  be 
years. 

3.  Initial  Starting  Offer  -  (range  0  to  30,000)  the  starting  value  that  you 
propose  for  this  issue.  To  use  the  scroll  bars  click  the  outer  arrows  to  increment  the 
value  by  one  and  the  inside  of  the  scroll  bars  to  increment  by  25. 

b.  To  add  a  new  issue  press  the  Add  New  Issue  button  and  a  new'  set  of 
textboxes  will  appear. 

c.  To  delete  an  issue  press  the  Delete  Issue  button  and  enter  the  number  of 
the  issue  you  want  to  delete. 

d.  You  can  enter  a  maximum  of  ten  issues  in  each  session. 


5.8  Entering  Issue  Priorities. 

a.  There  are  three  ways  of  assigning  issue  priorities: 

1.  Equal  Prioritization  -  all  issues  are  assigned  a  weighting  equal  to  \I{P 
of  issues).  If  equal  priority  is  chosen  the  program  w'ill  calculate  the  w'eighting  and 
display  it  in  a  message  box. 

2.  Direct  Prioritization  -  the  user  can  enter  an  individual  weighting  value 
for  each  issue.  If  direct  priority  is  chosen  a  screen  will  be  displayed  that  allow  s  you  to 
select  a  weighting  value  for  each  issue.  Allowable  values  are  between  0  and  10. 

3.  Pairwise  Comparison  -  the  user  indirectly  chooses  a  weighting  value 
b>  comparing  the  issues  to  each  other  in  pairs.  If  pairwise  comparison  is  chosen  a 
screen  will  be  displayed  that  asks  you  to  select  between  two  issues  at  a  time.  This 
process  w  ill  be  repeated  for  all  possible  combinations  of  issues.  The  program  will  then 
calculate  the  proper  weightings,  (not  available  in  version  1.0) 

5.9  Entering  Utility  Values.  After  selecting  the  Utility  Values  option  from  the 
Main  Selection  Menu  a  screen  will  be  displayed  that  allows  you  to  enter  your  utility 
values  for  each  issue. 

a.  There  are  seven  evenly  separated  range  points  associated  with  each  issue. 
The  range  for  each  issue  is  bounded  by  the  initial  starting  offer  of  each  party. 

b.  To  enter  utility  values  select  an  issue  from  those  available  in  the  leftmost 

box. 
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c.  For  each  of  the  issue’s  seven  range  points,  click  a  utility  button  that  best 
describes  your  desirability  for  that  point.  Utility  values  range  from  0  to  100  (0  being  no 
utility  and  100  being  maximum  utility). 

d.  Repeat  steps  b  and  c  for  all  issues. 

e.  After  entering  all  the  utility  values  select  the  OK  button. 

5.10  Displaving/Modifying  Negotiation  Results. 

a.  Select  the  Negotiation  Results  option  from  the  Main  Selection  Menu. 

b.  From  the  Negotiation  Results  screen  you  have  four  choices: 

1.  Display  issue  graphs  using  the  Display  Graphs  button. 

2.  Save  the  results  of  the  current  screen  in  ASCII  text  format  using  the 

Save  button. 

3.  Print  the  results  of  the  current  screen  to  the  active  printer  using  the 

Print  button. 

4.  Do  "what-if"  analysis  on  the  current  results  using  the  Scratch  Pad 
portion  of  the  screen. 

c.  To  do  "what-if  analysis  click  on  any  of  the  green  Descriptor  Value 
boxes.  Enter  any  value  desired  that  is  within  the  range  for  that  issue. 

d.  Press  the  Enter  key  on  your  keyboard  and  observe  the  newly  calculated 
utility  values  for  each  party.  Also  note  the  change  in  total  utility  at  the  bottom  of  the 
screen . 

e.  Scratch  Pad  values  initially  default  to  the  highest  joint  utility  values. 
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5. 1 1  Displaying  Graphs.  To  view  the  graphs  for  each  issue  you  must  first  select 
the  Negotiation  Results  option  from  the  Main  Selection  Menu. 

a.  Press  the  Display  Graphs  button  on  the  Negotiation  Results  screen. 

b.  Once  the  Graphs  screen  is  displayed  you  can  select  an  issue  in  the 
leftmost  box. 

c.  The  initial  screen  default  displays  the  graphs  using  weighted  values.  To 
select  unweighted  values  you  must  click  on  the  unweighted  option  button  at  the  bottom 
of  the  screen. 
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